Illustrated in FIG. 1 is a typical software change management repository 100 of the prior art. In a software change management repository 100, a set of objects 99 is maintained to capture the set of changes that have been requested by the developers and users of a software system. These changes request objects 99 are known by a variety of names in different change management repositories, such as Modification-Requests, Enhancement-Requests, Work-Items, Defects, and Bugs. In this disclosure, the term “Change-Request” is used to refer to these types of objects 99.
The information about a change request is captured in a set of properties of the Change-Request object 99. The property is represented by either an atomic value (such as a string, an integer, or a date) or a reference to another object 99 as illustrated by the ‘XX’ and dotted line arrow, respectively, of object 99a in FIG. 1. Some properties are pre-defined and present on all Change-Request objects 99, but most properties are determined by a customer, and can vary from project to project. The current state of a change request is summarized in a pre-defined State property 102 of the Change-Request object 99. Although the State property 102 is pre-defined, the legal values of the State property are determined by a customer. The customer defines a set of allowed transitions from one State value to another, and defines the actions that perform those transitions.
Some key problems with maintaining the state of a Change-Request object 99 are as follows:                1. Different stake-holders in the change management process have different perspectives on what the current state of a given Change-Request should be. For example, a developer might believe that the Issue is resolved, while the submitter of the Issue believes the Issue requires further work. One approach to this problem is to introduce composite states such as “open-development-pending”, “open-development-complete” and, “closed-development-complete”. This approach results in a combinatorial explosion in the number of states as the number of stake-holders in the Change-Request management process increases, which makes it difficult to introduce new stake-holders to the change management process.        2. Multiple users of a software system might report similar problems. If each of these problems is entered as a separate Change-Request object 99, it is error-prone and expensive to update the properties of each of these Change-Request objects as the problem is being resolved. If only a single Change-Request object 99 is used to track all of these problems, then it is difficult to capture important distinctions between the submitters of the problem, such as what release of the system was demonstrating the problem, and whether the problem has been resolved on the particular platform or product variant needed by a given user.        3. A given Change-Request might need to be resolved in different ways in multiple releases or variants of a given software system. It is important to be able to independently track how work is progressing in each of these releases or variants, but if there are separate Change-Request objects 99 for each release or variant, it is error-prone and expensive to update the problem description information on each of those change requests.        4. A given set of changes might be able to contribute to the completion of multiple tasks (especially when they are tasks to fix the same problem in different releases or variants of the software system). It is error-prone and expensive to be updating the multiple Change-Request objects 99 as work on that single activity progresses.        5. Different stake-holders in the change management process might be working at different sites with different replicas of the change management repository 100, or working disconnected with a personal replica of a subset of the change management repository 100. When multiple replicas are in use, different stake-holders can unwittingly modify the Change-Request object 99 in incompatible ways, resulting in difficult merge scenarios that require expensive manual merging or result in loss of information from automated merging. A standard solution to this problem is to assign one replica of the repository 100 as the master of a given Change-Request, and only users accessing that replica of the repository 100 can make any modifications to that Change-Request object 99. But this results in serious delays and loss of information as stake-holders wait for mastership to be transferred to their replica.        